Please follow the proposal template. You're missing some sections that I would expect to see for this type of proposal, in particular "Alternatives", "Security considerations", and "Unstable prefix".

Some possible alternatives:

• allow the homeserver to send an HTTP (3xx status code) on /media queries
• include the media server in the /login response, rather than in .well-known

Missng sections added in 86123b0.

Re: login response I don't think this works because media is accessible without authentication with a known MXID which login would prevent.

Re: login response I don't think this works because media is accessible without authentication with a known MXID which login would prevent.

That seems reasonable. I'd suggest still including that in the "Alternatives" section -- part of the purpose of that section is to indicate other possible ways to achieve the goal, and say why the proposed solution is better.

This needs expanding, or at least covering in the alternatives. As mentioned, for my own server I'm one flag away from having CDN-driven media without spec changes. Is there a particular CDN provider in mind for your use case which prevents working within the existing spec?

For reference, the setup I've been looking at is effectively deploying my own CDN on top of a cloud provider: there's a reverse proxy in several geographical areas using DNS to direct traffic there, with the media repo running in that datacenter to serve media from its CDN-backed backend (so all media is available everywhere). The traffic routing for client-server and server-server traffic is effectively unchanged in this setup, though might use a backbone back to the real server hosted in a single geographical area. The latency would be nearly the same as if a user was talking to the server over an ocean directly.

Granted, this is not a super cost effective solution, but it does work within how Matrix expects a server to operate. In practice, we'd also want to support proper geographically-segmented homeservers for traffic balancing in that respect, however that's much harder to do (and likely an implementation problem rather than spec).

A benefit of this proposal is it allows the media domain to be different from the homeserver domain, which is also something we want to do, though I do wonder if making the media repo be a proper first class citizen in the spec is a good idea.

Will add this to alternatives! The reverse proxy / CDN over everything solution certainly works but forces all traffic to be routed via that solution. Our use case specifically is we'd like to run Synapse inside AWS (as we currently do) but have the media routes served elsewhere due to AWS' prohibitive bandwidth costs. Without a separate domain the only option for that is a solution similar to yours where a matrix-aware reverse proxy needs to sit on the CDN side routing requests accordingly.

While this is certainly possible (cloudflare workers, fly.io, custom build CDN) it's represents a significant amount of work vs. a separate domain which to me feels like a very simple and easy solution. I can't see any negatives to doing this (esp. as an optional field).

Does having a separate domain really make the media repo a first class citizen? Perhaps there should be some kind of reliance on a homeserver to avoid that, or perhaps it's actually a good thing? (Multiple homeserver owners could share a media repo install or something along those lines, way beyond this proposal).

If it's for upload as well, I'm guessing the client is expected to use the same access token as it would use when communicating with the homeserver. Is that correct?